Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-028.txt

Text File | 1992-11-18 | 47.3 KB | 1,214 lines | [TEXT/MPS ]

C.S.M.P. Digest             Mon, 23 Mar 92       Volume 1 : Issue 28

Today's Topics:

    _ProtectMemory anyone ?
    Changing menu items during MenuSelect
    .pit - What program and where can I get it?
    Need help with seriell driver
    Still having trouble with Discipline...
     HELP WITH MODAL DIALOG/WINDOW CONFLIC
    question re 32-bit memory manager
    SpreadSheet interfaces, best way??


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Jon W{tte)
Subject: _ProtectMemory anyone ?
Date: 24 Jan 92 20:50:48 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden


No, it's not a bitch about wanting protected memory (which I do)

It's about the trap _ProtectMemmory; which recent Apple documentation
mentions by name (it's in the new ROMs) but I can't seem to find the
trap number or calling sequence...

Now, if I knew my application is not supposed to write outside its
heap, could I not write-protect all pages != my heap ? (and set them
back at WaitNextEvent, natch !)

Only trouble is; I don't know how to go about and use it :-(

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  _ProtectMemory anyone ?
Date: 28 Jan 92 23:24:09 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>
>No, it's not a bitch about wanting protected memory (which I do)
>
>It's about the trap _ProtectMemmory; which recent Apple documentation
>mentions by name (it's in the new ROMs) but I can't seem to find the
>trap number or calling sequence...
>
>Now, if I knew my application is not supposed to write outside its
>heap, could I not write-protect all pages != my heap ? (and set them
>back at WaitNextEvent, natch !)

I don't think so. How would you deal with asynchronous tasks (such as
VBL tasks, Time Manager Tasks, Asynch I/O) installed by processes other
than your own? For instance, if my application has a VBL task that
increments a counter, wouldn't it break if you protected my
application's global variable space while you were executing?

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  _ProtectMemory anyone ?
Date: 31 Jan 92 23:33:28 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Keith Rollin) writes:
> I don't think so. How would you deal with asynchronous tasks (such as
> VBL tasks, Time Manager Tasks, Asynch I/O) installed by processes other
> than your own? For instance, if my application has a VBL task that
> increments a counter, wouldn't it break if you protected my
> application's global variable space while you were executing?

The Device Manager is already doing some deferring, so VBL tasks
in general are not triggered durning a page handling. This
so the system could guarantee that the memory they touch is
guaranteed to be held. Dunno I know if that would help with
real semaphore handling concerning protection of shared data...

Anyway, TN285 talks in detail about these issues.

Kent Sandvik
- -----------
Haven't had a .signature since 1990.



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  _ProtectMemory anyone ?
Date: 28 Jan 92 23:24:09 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>
>No, it's not a bitch about wanting protected memory (which I do)
>
>It's about the trap _ProtectMemmory; which recent Apple documentation
>mentions by name (it's in the new ROMs) but I can't seem to find the
>trap number or calling sequence...
>
>Now, if I knew my application is not supposed to write outside its
>heap, could I not write-protect all pages != my heap ? (and set them
>back at WaitNextEvent, natch !)

I don't think so. How would you deal with asynchronous tasks (such as
VBL tasks, Time Manager Tasks, Asynch I/O) installed by processes other
than your own? For instance, if my application has a VBL task that
increments a counter, wouldn't it break if you protected my
application's global variable space while you were executing?

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  _ProtectMemory anyone ?
Date: 31 Jan 92 23:33:28 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Keith Rollin) writes:
> I don't think so. How would you deal with asynchronous tasks (such as
> VBL tasks, Time Manager Tasks, Asynch I/O) installed by processes other
> than your own? For instance, if my application has a VBL task that
> increments a counter, wouldn't it break if you protected my
> application's global variable space while you were executing?

The Device Manager is already doing some deferring, so VBL tasks
in general are not triggered durning a page handling. This
so the system could guarantee that the memory they touch is
guaranteed to be held. Dunno I know if that would help with
real semaphore handling concerning protection of shared data...

Anyway, TN285 talks in detail about these issues.

Kent Sandvik
- -----------
Haven't had a .signature since 1990.



---------------------------

From: [e-mail] (Russell Street)
Subject: Changing menu items during MenuSelect
Date: 27 Jan 92 19:50:03 GMT
Organization: University of Auckland, New Zealand.

How does one change menu items when the user is selecting
a menu. For instance when Option is being held down
change "Save" to "Save All" etc.  Or like Multifinder 6.1b?
did with it's "Set Aside" item.

There is a low memory global called MenuHook. If you install
a pointer to a routine there it gets called repeatedly when
the user is choosing menus.

If you change menu items using SetItem inside the MenuHook routine the
item name does not change if the user is looking at the menu.

Perhaps one needs to call the MDEF manually to force a redraw?
I tried to do this but with little success. I got stuck figuring
out where the menu lies in global coordinates.

Before you point out the bad user interface design of changing menu
items WHILE they are being selected, any hints on how to do this?


TIA
- -----------------------------------------------------
And with that remark, folks, the case of the Crown vs
Russell Street ([e-mail]) was proven.



- -------------------------

From: [e-mail] (Garth Dickie)
Subject:  Changing menu items during MenuSelect
Date: 27 Jan 92 21:46:33 GMT
Organization: Univ. of Wisconsin Dept. of Mathematics

[e-mail] (Russell Street) writes:

>How does one change menu items when the user is selecting
>a menu. For instance when Option is being held down
>change "Save" to "Save All" etc.  Or like Multifinder 6.1b?
>did with it's "Set Aside" item.

Canonical example: FullWrite Professional does (as with most
of its user interface) a beautiful job.

>There is a low memory global called MenuHook. If you install
>a pointer to a routine there it gets called repeatedly when
>the user is choosing menus.

Except when the user is holding the mouse over a heierarchical
menu's parent item!  This has been acknowledged as a bug.

>If you change menu items using SetItem inside the MenuHook routine the
>item name does not change if the user is looking at the menu.

>Perhaps one needs to call the MDEF manually to force a redraw?
>I tried to do this but with little success. I got stuck figuring
>out where the menu lies in global coordinates.

Um.  If you really want to hack it this way, it will be pretty
messy.  I don't think that there is any way to even come close
and not break all sorts of rules.

If I were doing this, I would probably involve a custom MDEF.  It
would be a bad idea to use a completely rewritten one, unless you
also need to disply option- and shift- key equivalents, because
the standard one will handle heierarchical submenus and scrolling,
which I don't really want to re-create if I ever need them.

Given the above, try writing a pass-through MDEF.  Make sure that
the longest item strings are in the menu when you call the system
MDEF to calculate the menu size, so there is enough room.  Keep
a copy of the destination rect when it is first drawn.  You get
a hit message with more than enough frequency to update your menus.
To handle the updates, set the clip of the WMgrPort to contain
just the items to be updated and pass a fake draw message to the
original MDEF.

If you are interested, I have code to handle calling an MDEF from
assembly, setting up all of the scrolling state, etc beforehand
and saving it after the call, so that you can manage a heierarchical
list of menus each of which may be redrawn at any time.

This is part of a forthcoming (to be placed in the public domain,
together with its source code) menu extension, Floating Menus,
which decouples menu selection from the event loop -- I'm mostly
happy with it, but the Help Manager does some very peculiar things :-).
--

garth dickie -- [e-mail] -- math agnostic (and student)



- -------------------------

From: [e-mail] (Larry Rosenstein)
Subject:  Changing menu items during MenuSelect
Date: 31 Jan 92 03:03:16 GMT
Organization: Object Based Systems, Apple Computer, Inc.

In article <[e-mail]> [e-mail] (Garth Dickie) writes:
>
>Canonical example: FullWrite Professional does (as with most
>of its user interface) a beautiful job.

FullWrite doesn't use the Menu Manager unless it has to.  For example, in
the 1.5 version the System 7 help and application menus don't work.  In the
1.5s version, they call the Menu Manager if you click on one of those menus,
but then the items don't change dynamically.  If you click on one of their
own menus, then you can't drag over to the help/app menus.

--
Larry Rosenstein, Apple Computer, Inc.

[e-mail]
(or AppleLink: Rosenstein1)



- -------------------------

From: [e-mail] (Larry Rosenstein)
Subject:  Changing menu items during MenuSelect
Date: 31 Jan 92 03:03:16 GMT
Organization: Object Based Systems, Apple Computer, Inc.

In article <[e-mail]> [e-mail] (Garth Dickie) writes:
>
>Canonical example: FullWrite Professional does (as with most
>of its user interface) a beautiful job.

FullWrite doesn't use the Menu Manager unless it has to.  For example, in
the 1.5 version the System 7 help and application menus don't work.  In the
1.5s version, they call the Menu Manager if you click on one of those menus,
but then the items don't change dynamically.  If you click on one of their
own menus, then you can't drag over to the help/app menus.

--
Larry Rosenstein, Apple Computer, Inc.

[e-mail]
(or AppleLink: Rosenstein1)



---------------------------

From: [e-mail] (Mark B Palmerino)
Subject: .pit - What program and where can I get it?
Date: 28 Jan 92 16:42:06 GMT
Organization: Harvard University, Cambridge, MA

Hi,

I just picked up a program (xlisp) from plains.nodak.edu and when I
de-hqx'd it I got the following file: xlisp.pit

I'm not familiar with the .pit extension but presume that it is some sort
of an archived or otherwise bundled file.

Does anyone know what application I need to get at the stuff inside and,
more importantly, where I can get said program?

Thanks alot!

--
Mark Palmerino      [e-mail]       Voice: [phone]



- -------------------------

From: [e-mail] (Tony Wingo)
Subject:  .pit - What program and where can I get it?
Date: 1 Feb 92 00:34:22 GMT
Organization: Apple Computer

In article <[e-mail]>, [e-mail] (Mark B Palmerino) writes:
>
> Hi,
>
> I just picked up a program (xlisp) from plains.nodak.edu and when I
> de-hqx'd it I got the following file: xlisp.pit
>
> I'm not familiar with the .pit extension but presume that it is some sort
> of an archived or otherwise bundled file.
>
> Does anyone know what application I need to get at the stuff inside and,
> more importantly, where I can get said program?
>
pit files were compressed with PackIT, the first of ther Mac Archivers, now
superceeded.  You can probably find a copy on one of the ftp sites, but you
shouldn't have to since to the best of knowlege Stuffit will unpack .pit files.

-tony

>>usual disclaimer<<



- -------------------------

From: [e-mail] (Tony Wingo)
Subject:  .pit - What program and where can I get it?
Date: 1 Feb 92 00:34:22 GMT
Organization: Apple Computer

In article <[e-mail]>, [e-mail] (Mark B Palmerino) writes:
>
> Hi,
>
> I just picked up a program (xlisp) from plains.nodak.edu and when I
> de-hqx'd it I got the following file: xlisp.pit
>
> I'm not familiar with the .pit extension but presume that it is some sort
> of an archived or otherwise bundled file.
>
> Does anyone know what application I need to get at the stuff inside and,
> more importantly, where I can get said program?
>
pit files were compressed with PackIT, the first of ther Mac Archivers, now
superceeded.  You can probably find a copy on one of the ftp sites, but you
shouldn't have to since to the best of knowlege Stuffit will unpack .pit files.

-tony

>>usual disclaimer<<



---------------------------

From: [e-mail] (Marcel Claus)
Subject: Need help with seriell driver
Date: 30 Jan 92 11:52:14 GMT
Organization: University of Oldenburg, Germany

In system version 6 there was a function RamSDOpen opening the seriell
RAM drivers and closing the ROM driver. In system version 7 this command
doesn't exist anymore.
My problem is how to read data (ASCII characters, odd-parity, 1 stop bit,
9600 baud, transfer mode can still be setted with the SerReset command)
in the RAM. The program is written in MPW C.
The incoming data is a simple datastream from a not programmable machine,
so there is no protocoll available.
My question is if there is any command or inside macintosh call to open
the RAM driver (for example with OpenDriver(????)) and close the ROM
driver (possibly with CloseDriver(????); I didn't found the resource names
for those calls in the inside macintosh volumes) or another way to read
the incoming data (possibly with a modified Appletalk call).

Thanx to all sendfing me some help.  Marcel



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  Need help with seriell driver
Date: 1 Feb 92 03:28:43 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (Marcel Claus) writes:
>
> In system version 6 there was a function RamSDOpen opening the seriell
> RAM drivers and closing the ROM driver. In system version 7 this command
> doesn't exist anymore.
> My problem is how to read data (ASCII characters, odd-parity, 1 stop bit,
> 9600 baud, transfer mode can still be setted with the SerReset command)
> in the RAM. The program is written in MPW C.
> The incoming data is a simple datastream from a not programmable machine,
> so there is no protocoll available.
> My question is if there is any command or inside macintosh call to open
> the RAM driver (for example with OpenDriver(????)) and close the ROM
> driver (possibly with CloseDriver(????); I didn't found the resource names
> for those calls in the inside macintosh volumes) or another way to read
> the incoming data (possibly with a modified Appletalk call).
>
> Thanx to all sendfing me some help.  Marcel

OK... this is the last time I'm answering this, cause I'm going to save it
this time and send it to our illustrious FAQ editor....  The declarations of
RAMSDOpen and RAMSDClose has been removed from MPW 3.2 and Think C 5.0.  It was intended
solely as a support routine for 64K ROMs- because these machines are no
longer supported by the MPW compilers, most of the routines intended for
those machines only were removed from the interfaces and libraries.  Because
Symantec bases its interfaces on Apple's, they were removed from the Think
interfaces also.  Instead, you should use OpenDriver and CloseDriver to open
and close the serial ports; it is no longer necessary to check whether AppleTalk
is open or not; the drivers will do all this for you.  There is an entire tech
note on this subject; it is #249, "Opening the Serial Driver".  I'm pasting
it below.

Tim Dierks
MacDTS, but I speak for myself

#249:    Opening the Serial Driver

Revised by:    Sriram Subramanian                               December 1989
Written by:    Sriram Subramanian                                 August 1989

This Technical Note describes the recommended, safe, and compatible way to
open the Macintosh serial driver, and it explains why you should no longer
check for port availability.
Changes since October 1989:  Corrected syntax errors in the sample code.
_____________________________________________________________________________

Starting with the 128K ROM, we recommend that applications do not check the
low-memory globals SPConfig, PortAUse, and PortBUse before opening the serial
driver.  It is no longer the applicationUs responsibility to test for the
availability of the serial ports.  When running AppleTalk Phase 2, it is now
possible to use the printer port for asynchronous serial communication while
AppleTalk is active and using an alternate connection, such as EtherTalk or
TokenTalk.

The serial driver automatically verifies that the serial port is correctly
configured and free for an asynchronous driver; if it is not correctly
configured or free, the serial driver returns either the result code
portNotCf or portInUse.  The serial driver already has all the code built
into it for testing the availability of the serial ports before trying to
complete the _Open call.  Therefore, since all of the required checks are
made inside the driver itself, we recommend that a simple OpenDriver call
be made when you need to use a serial port.

By using just the OpenDriver call to the serial driver, you ensure that
your code is both user-friendly and compatible with future versions of
the System Software.

Pascal

result := OpenDriver('.AOut',AoutRefNumber);
                            { Check result codes in a real application. }
result := OpenDriver('.AIn',AinRefNumber);
                            { See failure mechanism in Sample Code.     }

C

result = OpenDriver("\p.AOut",&AoutRefNumber);
                            /* Check result codes in a real application.*/
result = OpenDriver("\p.AIn",&AinRefNumber);
                            /* See failure mechanism in Sample Code.    */

If you must maintain compatibility with the 64K ROMs, call _SysEnvirons,
then either call RAMSDOpen for the 64K ROM machines or OpenDriver for the
others.


Further Reference:
_______________________________________________________________________________
  %  Inside Macintosh, Volume II-249, The Serial Driver
  %  Inside Macintosh, Volume IV-225, The Serial Driver
  %  Technical Note #129, _SysEnvirons:  System 6.0 and Beyond
  %  DTS Q & A Stack



- -------------------------

From: [e-mail] (Nick Rothwell)
Subject:  Need help with seriell driver
Date: 3 Feb 92 12:49:19 GMT
Organization: Friends of the Salter Duck

Another FAQ perhaps, but: shouldn't we all be cleaner-than-clean and
using the Communications Toolbox these days?

    Nick.
--
Nick Rothwell, LFCS, Edinburgh | "Chai ch t'chai ch't chnna chnna chnna ch'th
             [e-mail] |  Chai ch t'chai ch't chuth chena chann ch'tt
Mentation Consultancy Services |  Chie ch t'chie ch t'chaaa chn chattr chattr"
   [e-mail] |       -- Wavestation, V3 software, my dragon.



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  Need help with seriell driver
Date: 1 Feb 92 03:28:43 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (Marcel Claus) writes:
>
> In system version 6 there was a function RamSDOpen opening the seriell
> RAM drivers and closing the ROM driver. In system version 7 this command
> doesn't exist anymore.
> My problem is how to read data (ASCII characters, odd-parity, 1 stop bit,
> 9600 baud, transfer mode can still be setted with the SerReset command)
> in the RAM. The program is written in MPW C.
> The incoming data is a simple datastream from a not programmable machine,
> so there is no protocoll available.
> My question is if there is any command or inside macintosh call to open
> the RAM driver (for example with OpenDriver(????)) and close the ROM
> driver (possibly with CloseDriver(????); I didn't found the resource names
> for those calls in the inside macintosh volumes) or another way to read
> the incoming data (possibly with a modified Appletalk call).
>
> Thanx to all sendfing me some help.  Marcel

OK... this is the last time I'm answering this, cause I'm going to save it
this time and send it to our illustrious FAQ editor....  The declarations of
RAMSDOpen and RAMSDClose has been removed from MPW 3.2 and Think C 5.0.  It was intended
solely as a support routine for 64K ROMs- because these machines are no
longer supported by the MPW compilers, most of the routines intended for
those machines only were removed from the interfaces and libraries.  Because
Symantec bases its interfaces on Apple's, they were removed from the Think
interfaces also.  Instead, you should use OpenDriver and CloseDriver to open
and close the serial ports; it is no longer necessary to check whether AppleTalk
is open or not; the drivers will do all this for you.  There is an entire tech
note on this subject; it is #249, "Opening the Serial Driver".  I'm pasting
it below.

Tim Dierks
MacDTS, but I speak for myself

#249:    Opening the Serial Driver

Revised by:    Sriram Subramanian                               December 1989
Written by:    Sriram Subramanian                                 August 1989

This Technical Note describes the recommended, safe, and compatible way to
open the Macintosh serial driver, and it explains why you should no longer
check for port availability.
Changes since October 1989:  Corrected syntax errors in the sample code.
_____________________________________________________________________________

Starting with the 128K ROM, we recommend that applications do not check the
low-memory globals SPConfig, PortAUse, and PortBUse before opening the serial
driver.  It is no longer the applicationUs responsibility to test for the
availability of the serial ports.  When running AppleTalk Phase 2, it is now
possible to use the printer port for asynchronous serial communication while
AppleTalk is active and using an alternate connection, such as EtherTalk or
TokenTalk.

The serial driver automatically verifies that the serial port is correctly
configured and free for an asynchronous driver; if it is not correctly
configured or free, the serial driver returns either the result code
portNotCf or portInUse.  The serial driver already has all the code built
into it for testing the availability of the serial ports before trying to
complete the _Open call.  Therefore, since all of the required checks are
made inside the driver itself, we recommend that a simple OpenDriver call
be made when you need to use a serial port.

By using just the OpenDriver call to the serial driver, you ensure that
your code is both user-friendly and compatible with future versions of
the System Software.

Pascal

result := OpenDriver('.AOut',AoutRefNumber);
                            { Check result codes in a real application. }
result := OpenDriver('.AIn',AinRefNumber);
                            { See failure mechanism in Sample Code.     }

C

result = OpenDriver("\p.AOut",&AoutRefNumber);
                            /* Check result codes in a real application.*/
result = OpenDriver("\p.AIn",&AinRefNumber);
                            /* See failure mechanism in Sample Code.    */

If you must maintain compatibility with the 64K ROMs, call _SysEnvirons,
then either call RAMSDOpen for the 64K ROM machines or OpenDriver for the
others.


Further Reference:
_______________________________________________________________________________
  %  Inside Macintosh, Volume II-249, The Serial Driver
  %  Inside Macintosh, Volume IV-225, The Serial Driver
  %  Technical Note #129, _SysEnvirons:  System 6.0 and Beyond
  %  DTS Q & A Stack



---------------------------

From: [e-mail] (Brady Duga)
Subject: Still having trouble with Discipline...
Date: 11 Feb 92 19:39:58 GMT
Organization: Center for Visual Science, U. of Rochester

I'm still having toruble with Discipline on a Quadra. The combination of
Discipline (2.0.1) and MacsBug (6.2.2) works fine on a Mac II (sys 6.0.5).
However, I still get an "Unknown error due to debugger" on the Quadra
(sys 7.0.1, no TuneUp yet). One odd point: on the MacII, the startup message
says "MacsBug Installed". On the Quadra, it says "Debugger installed".
Should this happen? I could really use some Discipline :)

--Brady ([e-mail])



- -------------------------

From: [e-mail] (david_powell)
Subject:  Still having trouble with Discipline...
Date: 20 Feb 92 23:16:02 GMT
Organization: Apple Federal

You need Discipline 2.0.2 or later and MacsBug 6.3 for a Quadra.

The change in startup messages is due to the system software version
differences (6.x sez Macsbug and 7.x sez Debugger installed).--

In article <[e-mail]>, [e-mail] (Brady Duga) writes:
>
> I'm still having toruble with Discipline on a Quadra. The combination of
> Discipline (2.0.1) and MacsBug (6.2.2) works fine on a Mac II (sys 6.0.5).
> However, I still get an "Unknown error due to debugger" on the Quadra
> (sys 7.0.1, no TuneUp yet). One odd point: on the MacII, the startup message
> says "MacsBug Installed". On the Quadra, it says "Debugger installed".
> Should this happen? I could really use some Discipline :)
>
> --Brady ([e-mail])
>
>

--
david powell
Apple Federal Systems Group
[e-mail]



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Still having trouble with Discipline...
Date: 21 Feb 92 03:04:26 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (david_powell) writes:
>
> You need Discipline 2.0.2 or later and MacsBug 6.3 for a Quadra.

6.2.2 works just fine on my Quadra, if not I would take my bike to
DTE-land. There are some 6.3d releases floating around out there, and
those are certainly not tested or debugged yet. I would try to use
the later Discipline versions (2.0.2) (available on the infamous ETO#6)
to see if the problem is still there.

Kent Sandvik
"Dynamic Language Evangelist"
not speaking for DTS



---------------------------

From: [e-mail] (Henry Sohn)
Subject:  HELP WITH MODAL DIALOG/WINDOW CONFLIC
Date: 6 Feb 92 16:09:48 GMT
Organization: FidoNet node 1:161/444 - BMUG, Berkeley CA

I too am just starting with the Mac Pascal Programming Primer and find it a
valuable resource.  Although I don't have a solution to your situation
(hopefully that last message resolved it), I thought I might take this
opportunity to ask if you or anyone else knows where Volume II of this book
supposed to be.  Volume I refers to it, and it apparently continues with
Color QuickDraw and other advanced topics.  There is a Volume II for C, but I
haven't been able to find Volume II for Pascal.  Any ideas?

Thanks in advance, and Happy Hacking...

Henry S.

--
Henry Sohn - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!161!444!Henry.Sohn
INTERNET: [e-mail]



- -------------------------

From: [e-mail] (jonathan abel lieberman)
Subject:  HELP WITH MODAL DIALOG/WINDOW CONFLIC
Date: 21 Feb 92 07:39:49 GMT
Organization: University of Chicago Computing Organizations

I have tried to find voloume II as well.  I tried to order it when I couldn't
find it, and I was told that it doesn't exist, despite the references to it
in vol. I.
______________________________________________________________________________
Jonathan Lieberman     [e-mail]           No silly quote...



---------------------------

From: [e-mail] (David Swofford )
Subject: question re 32-bit memory manager
Date: 14 Feb 92 20:19:40 GMT
Organization: University of Illinois at Urbana


Does anyone know if there is a limit of 16M on the size of a single
memory block under System 7 32-bit addressing?  I can't find any mention
of such a limit in Inside Mac V6, but if the block header is still as
described in  IM 2, only 24 bits are available to store the size of the
block.  The reason this is relevant is that I've written some code to
walk through the application heap and examine every block and I want to
make sure it will work under 32-bit addressing.  (It works fine on
System 7 under 24-bit addressing but I don't have access to a machine
that can run in 32-bit mode.)

IM 6 DOES say "never make assumptions about the contents of Memory
Manager data structures" (p. 3-6).  I would like to abide by this, but
does anyone know how a program can get pointers to all allocated memory
blocks without knowing how the block headers are structured?
--
David L. Swofford                 Phone:    [phone]
Illinois Natural History Survey   FAX:      [phone]
607 E. Peabody Drive              BITNET:   DAVESWOF@UIUCVMD
Champaign, Illinois 61820 USA     Internet: [e-mail]



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  question re 32-bit memory manager
Date: 17 Feb 92 01:34:10 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (David Swofford ) writes:
> Does anyone know if there is a limit of 16M on the size of a single
> memory block under System 7 32-bit addressing?  I can't find any mention
> of such a limit in Inside Mac V6, but if the block header is still as
> described in  IM 2, only 24 bits are available to store the size of the
> block.  The reason this is relevant is that I've written some code to
> walk through the application heap and examine every block and I want to
> make sure it will work under 32-bit addressing.  (It works fine on
> System 7 under 24-bit addressing but I don't have access to a machine
> that can run in 32-bit mode.)
>
> IM 6 DOES say "never make assumptions about the contents of Memory
> Manager data structures" (p. 3-6).  I would like to abide by this, but
> does anyone know how a program can get pointers to all allocated memory
> blocks without knowing how the block headers are structured?

The block and heap structures have changed with 32-bit addressing; your
code will not work on a 32-bit machine.  There isn't any reasonable way
to get the addresses of all allocated memory blocks without knowledge of
heap data structures.  Fortunately, most programs don't need this capability;
any that do lock themselves to a particular version of the heap structures.

Any Mac can be run in 32-bit mode with the addition of Mode32, available from
ftp.apple.com.

Tim Dierks
MacDTS, but I speak for myself



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  question re 32-bit memory manager
Date: 17 Feb 92 03:08:52 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Tim Dierks, ToyMeister, Cray abuser) writes:
>
> In article <[e-mail]>, [e-mail] (David Swofford ) writes:
> > IM 6 DOES say "never make assumptions about the contents of Memory
> > Manager data structures" (p. 3-6).  I would like to abide by this, but
> > does anyone know how a program can get pointers to all allocated memory
> > blocks without knowing how the block headers are structured?
>
> The block and heap structures have changed with 32-bit addressing; your
> code will not work on a 32-bit machine.  There isn't any reasonable way
> to get the addresses of all allocated memory blocks without knowledge of
> heap data structures.  Fortunately, most programs don't need this capability;
> any that do lock themselves to a particular version of the heap structures.

Hi Tim, anyway developers should *never* assume that internal block and heap
structures will be rock solid. There's a lot of work going on inside Apple
(you all know what...) and don't ever trust OS internals concerning the future.
For instance in the A/UX case NewHandle/NewPtr calls are done using UNIX malloc
(really brk/sbrk) calls, so you can't assume that memory blocks are exactly the
same in various emulated environments.

Kent Sandvik
not speaking for MacDTS mongols, was it?



- -------------------------

From: [e-mail] (Steve Dorner)
Subject:  question re 32-bit memory manager
Organization: University of Illinois at Urbana-Champaign
Date: Tue, 18 Feb 1992 19:00:04 GMT

[e-mail] (Kent Sandvik) writes:
>> In article <[e-mail]>, [e-mail] (David Swofford ) writes:
>> > IM 6 DOES say "never make assumptions about the contents of Memory
>> > Manager data structures" (p. 3-6).  I would like to abide by this, but
>> > does anyone know how a program can get pointers to all allocated memory
>> > blocks without knowing how the block headers are structured?
>anyway developers should *never* assume that internal block and heap
>structures will be rock solid.

I've worked with Dave on this a bit.  His problem is that the system is
not rock solid.

In fact, the print manager is leaving little turds in his heap; the turds
are disembodied copies of the paper type popup menu.  He's using code
suggested by DTS, BTW.

So, he can either a) walk the heap looking for and removing these things
b) poke around the print manager trying to find a pointer to them
or c) put up with losing 100 bytes every time a user does a page preview.

I don't blame him for thinking a) is the safest alternative.
--
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  question re 32-bit memory manager
Date: 21 Feb 92 05:35:11 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Steve Dorner) writes:
>
> [e-mail] (Kent Sandvik) writes:
> >> In article <[e-mail]>, [e-mail] (David Swofford ) writes:
> >> > IM 6 DOES say "never make assumptions about the contents of Memory
> >> > Manager data structures" (p. 3-6).  I would like to abide by this, but
> >> > does anyone know how a program can get pointers to all allocated memory
> >> > blocks without knowing how the block headers are structured?
> >anyway developers should *never* assume that internal block and heap
> >structures will be rock solid.
>
> I've worked with Dave on this a bit.  His problem is that the system is
> not rock solid.
>
> In fact, the print manager is leaving little turds in his heap; the turds
> are disembodied copies of the paper type popup menu.  He's using code
> suggested by DTS, BTW.

> So, he can either a) walk the heap looking for and removing these things
> b) poke around the print manager trying to find a pointer to them
> or c) put up with losing 100 bytes every time a user does a page preview.
>
> I don't blame him for thinking a) is the safest alternative.

True, however we should fix this, so please send the snippet over
here so we could examine the case. I'm sure our DTS printing people
will take a careful look at the problem. If possible state the release
levels of the print drivers and the system so it's easier to narrow
the problem.

I will be away from the office for 14 days, if I don't get it by Friday afternoon
I can't do much about the problem. Send it to [e-mail]
as well so it will be included into the bug database.

Actually, if you send the material to [e-mail], I could
forward it to the right people next week (will check my ALink emails with
my portable).

Kent Sandvik/DTS
- --
not speaking nor working for DTS just now



---------------------------

From: [e-mail]
Subject: SpreadSheet interfaces, best way??
Date: 17 Feb 92 16:04:09 GMT
Organization: BC Systems Corporation

Hi again!!  I want to implement a "spreadsheet" style interface to the graphics
program I'm writing.  Basically, the program reads a data file (using reset,
etc for now until I figure out how to extract text using the SFGet routines)
and I want to display the data read in a spread sheet before graphing.

I have 2 problems, I'm using the List Manager to set up the "cells" in a
window.  The grid is 5 x 10 cells.  After setting up the cells in memory, I
want to outline them like Excel and other spreadsheets. However, I can't seem
to get this to work.  Here is what the code looks like:

{ Set up the 5 x 10 list already, now go to each cell in the list and frame it}

for i := 0 to 9 do    { the list manager is 0 based }
  for j := 0 to 4 do
    begin
      theCell.h := i;
      theCell.v := j;
      LRect(aCellRect,theCell,theList);
      FrameRect(aCellRect);
    end;    { for i }

LUpdate...

It sets up the cells fine, but it doesn't draw them.  I have drawing on and I
call an LDoDraw(TRUE,theList) in this procedure.  Any ideas??

My second problem is with LSetCell.  It takes a pointer the the data that you
want to put in the cell as well as the length of the data.  How can you use
this when you've read your data in as integers into an array:

    Readln(FType,Tests[i]);
        { where Tests:array[1..4] of integer }

Should I be reading the data in as a string?? or is there a better way in which
to go about this???

Thanks in advance.

--
[e-mail]
British Columbia, Canada



- -------------------------

From: [e-mail] (Ben Haller)
Subject:  SpreadSheet interfaces, best way??
Date: 18 Feb 92 10:16:19 GMT
Organization: Stick Software

In article <[e-mail]>
   [e-mail] writes:
>I have 2 problems, I'm using the List Manager to set up the "cells" in a
>window.  The grid is 5 x 10 cells.

  I have some good advice for you: don't use the List Manager.  Apple
has often been quoted as saying "The Resource Manager is not a databse".
Similarly, the List Manager is not a spreadsheet.  It is (IMHO) only
suited for the simplest and most trivial of applications.  Duplicating its
functionality with your own code, which you can then revise to behave the
way you want it to, should take a very small amount of code.
  I have often wondered why Apple bothers making these half-assed managers.
If they actually were to write good, bug-free, general code, less people
might be inclined to go around the operating system...

-Ben Haller ([e-mail])
"Operating system?  What operating system?"



- -------------------------

From: [e-mail] (Eric W. Sink)
Subject:  SpreadSheet interfaces, best way??
Organization: University of Illinois at Urbana-Champaign
Date: Tue, 18 Feb 1992 15:00:29 GMT

In <[e-mail]> [e-mail] (Ben Haller) writes:

>In article <[e-mail]>
>   [e-mail] writes:
>>I have 2 problems, I'm using the List Manager to set up the "cells" in a
>>window.  The grid is 5 x 10 cells.

>  I have some good advice for you: don't use the List Manager.  Apple

Suggestion: Use the Table class in the Think Class Library.  That's what
it's there for...

--
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]



- -------------------------

From: [e-mail] (Steve Dorner)
Subject:  SpreadSheet interfaces, best way??
Organization: University of Illinois at Urbana-Champaign
Date: Tue, 18 Feb 1992 15:41:40 GMT

[e-mail] (Ben Haller) writes:
>  I have often wondered why Apple bothers making these half-assed managers.

Apple wrote several of the managers because they needed them in the OS.
Then they say, "Hey, maybe somebody else could use this", and they document
it. Then they tell us "you really shouldn't use this for real work".

It *is* a weird process, no mistake.

I think the key to "don't abuse the managers" is that they were all written
for incidental use.  Yes, the list manager isn't the thing to use for
Lotus 123; but it's fine for a list of files, or a couple dozen inputs
in a table.  Yes, TextEdit isn't FullWrite Pro; but it's fine for small
blocks of text.  No, you don't implement the control panel for a space
shuttle simulator with the Dialog Manager, but it's great for grabbing
a few items.

Anyway, the point I'm failing to make here is that the managers are fine
for everything except the Central Core of your program, it's Reason To
Exist.  Use the managers for the periphery, and you'll do fine.

>If they actually were to write good, bug-free, general code, less people
>might be inclined to go around the operating system...

Unless I'm mistaken, that's (part of) what MacApp's intended to be.
--
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner



- -------------------------

From: [e-mail] (Mark Lanett)
Subject:  SpreadSheet interfaces, best way??
Date: 18 Feb 92 17:11:22 GMT
Organization: University of Illinois at Urbana

[e-mail] (Steve Dorner) writes:

>[e-mail] (Ben Haller) writes:
>>If they actually were to write good, bug-free, general code, less people
>>might be inclined to go around the operating system...

>Unless I'm mistaken, that's (part of) what MacApp's intended to be.

Yes. Eric just suggested using the TCLs Table class; I was going to suggest
using MacApp's TGridView (which also has TTextGridView and TTextListView
subclasses already for you). In fact in GelReader I implemented a *real* type-
on-it spreadsheet using that and a locatable TEditText... (which was a real
bitch, too. I did it at least 3 times and still am not happy with it).
--
Mark Lanett                                                   [e-mail]
Software Tools Group, NCSA, University of Illinois at Urbana-Champaign



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  SpreadSheet interfaces, best way??
Date: 20 Feb 92 08:54:01 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Ben Haller) writes:
>
> In article <[e-mail]>
>    [e-mail] writes:
> >I have 2 problems, I'm using the List Manager to set up the "cells" in a
> >window.  The grid is 5 x 10 cells.
>
>   I have some good advice for you: don't use the List Manager.  Apple
> has often been quoted as saying "The Resource Manager is not a databse".
> Similarly, the List Manager is not a spreadsheet.  It is (IMHO) only
> suited for the simplest and most trivial of applications.  Duplicating its
> functionality with your own code, which you can then revise to behave the
> way you want it to, should take a very small amount of code.
>   I have often wondered why Apple bothers making these half-assed managers.
> If they actually were to write good, bug-free, general code, less people
> might be inclined to go around the operating system...

Yes, as Steve pointer out, MacApp has GridViews and other things which makes
it easy to implement view lists, even with automatic key selection (MacApp 3.0
has a special behavior which will scroll the list based on the first keystrokes,
all you need to do is to write two lines of code).

Now, do people use MacApp? Usually not because they then complain about the performance
issues (which are not really that bad), the high threshold concerning learning
the object framework (which is a valid reason in some cases), and the compile and
linking times (now we start to have valid problems...).

I think we all agree that there's a time and place for every technique, library
and trick. Sometimes MacApp is the quickest way to create something concerning
time-to-market worries (which is a more and more vital issue today).
Sometimes a small neat C program is the right design idea for an application
(fast graphical games for instance). The Managers are really there to provide
the entry level functionality which should then be expanded in the application
itself. But in general we are nowadays providing new managers with more
and more built-in functionality (cmp QuickTime and CTB).

One final note about MacApp, if nothing else use MacApp as a library full
of ideas which could be used in your own application. I'm always amazed over
small nuggets of Mac code I could steal from the MacApp framework itself.

Kent Sandvik
..not speaking for Apple, nor DTS, nor the German branch of the Rush fan club.



- -------------------------

From: [e-mail] (Larry Rosenstein)
Subject:  SpreadSheet interfaces, best way??
Date: 21 Feb 92 18:38:40 GMT

In article <[e-mail]>, [e-mail] (Ben
Haller) writes:
>
>   I have often wondered why Apple bothers making these half-assed managers.
> If they actually were to write good, bug-free, general code, less people
> might be inclined to go around the operating system...

There's a place for things like TextEdit and the ListManager.  You don't need a
full-blown table editor when all you want is a list of a couple hundred strings,
or an editable field in a dialog box.

--
Larry Rosenstein
[e-mail]



---------------------------

End of C.S.M.P. Digest
**********************